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BACKGROUND 

Technical Field: 

20 The invention is related to a system and process for automatically 

remotely controlling the security state of an Internet web page having at least two 
frames wherein the web page is displayed via an Internet browser or other 
^ application for displaying Internet web pages. 

25 Related Art: 

By way of background, existing schemes using frame-based display of 
third-party web pages typically use hyperlinks within a frame to point to a third- 
party web page. User selection of such a hyperlink typically causes a frame 
30 within the window of an Internet browser to be replaced with the third party web 
page. However, if the hyperlink points to a third party web page requiring SSL, 
such as by using an HTTPS address, the frame replaced with the third party web 
page will be secure, while the remaining frames within the window will remain in 
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invention uses tlie same script and HTML for all implementations of the Web 
Component, regardless of which, or how many, unique local clients make use of 
the Web Component to automatically remotely control the security state of a web 
page and any associated frames. This code reuse is accomplished by using 
5 entry web pages, or "entry points," as described in further detail below, to set the 
value of function properties or parameters of the Web Component for 
dynamically and automatically remotely controlling the security state of a web 
page and any associated frames. The script and/or HTML of the Web 
Component pages does not change based on each new implementation or 
10 instantiation. Consequently, little setup work is required for each implementation, 
and only a basic verification test pass is completed for the implementation. 



Additionally, in a further embodiment, these Web Components are also 
useful for automatically generating uniquely customized web pages. In this 

1 5 context, at least one dynamically customizable Web Component is provided on a 
remote server to define what information (i.e. the information content) will be in a 
web page displayed by the Internet browser on a local client or transmitted to the 
Internet browser by the local client. In this context, a "local client" refers to a 
local client, a web server, a web site, a web page, an end-user computer, a 

20 specific server hosting web pages, any server or web page request originating 

from specific domains or IP addresses, any other computer system or application 
capable of accessing the remote server, or any combination of the 
aforementioned computers, servers, applications or processes. Examples of 
types of information that may be displayed include, for example, text, images 

25 (motion or still), audio data, applets, scripts, forms, hyperlinks, or any other data, 
information, or content that can be provided via the Internet from a remote server 
to a local client. 



Further, in one embodiment, the Web Component defines how the 
30 displayed information will appear to a user, i.e. the color, style, layout, border, 
background, font size, type, style and characteristics, or any other desired 
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parameters for defining the appearance of the information displayed by the 
Internet browser on the local client. 

In another embodiment, alternate images for each individual instantiation 
5 of the Web Component are preferably stored in at least one computer readable 
storage medium including a database, script, or other electronic file addressable 
by the Web Component, using a file path stored as a parameter of the instance 
of the Web Component for dynamically and automatically generating the web 
page. Similarly, in another embodiment, text files that contain Web Component- 
10 specific textual data are preferably copied and/or altered, again using one or 

more file paths stored as a parameters of the instance of the Web Component for 
dynamically and automatically generating the web page. Use of alternate images 
ii and/or text files, as described for the preceding embodiments, provides for 

simple customization of the Web Component by providing the ability to pre-define 
1 5 items such as images and/or text for use in specific instantiations of the Web 
|; Component. 

p Finally, in another embodiment, the system and process of the present 

invention employs each of the aforementioned embodiments, or any combination 

Z[ 20 thereof in automatically defining the information displayed in at least one web 

page, the appearance of that information, and the security state of the displayed 
window and associated frames for the web page. 

In general, the Web Component represents at least one dynamically 
25 configurable web page, and is comprised of at least one encapsulated web- 
based feature or function for defining one or more of security state, information 
content, and information appearance as described above. Consequently, one or 
more unique Web Components can be combined to form a complete web site, or 
portions thereof. The Web Component is customizable in that it is automatically 
30 and dynamically configured by setting one or more function properties associated 
with each function in response to a communication to the remote server from a 



-4- 



whatever state they were in at the time that the hyperlink was selected or 
activated by the user. Consequently, a mixture of secure and non-secure frames 
will exist within the same browser or application window, thereby typically 
causing the end user to be warned of the mix of secure and insecure content and 
5 preventing the browser from enabling the security icons which indicate a 
completely encrypted connection. 

Further, in some cases, a hyperlink in a frame may point to a non-HTTPS 
address that is subsequently redirected by the non-HTTPS address to an HTTPS 
1 0 address. In such cases, there will again be a mixture of secure and non-secure 
frames existing within the same window. Consequently, in such cases, a typical 
end user would feel unsafe in sending confidential information, such as, for 
example, credit numbers, or social security numbers, over the Internet via the 
mixed-security window. 



15 



20 



Therefore, what is needed is a system and method for automatically 
remotely controlling the security state of a web page and any frames associated 
with that web page. 



SUMMARY 



The present invention involves a new system and process for 
25 automatically controlling whether a displayed web page and associated frames 
displayed within a window of a web browser are secure or non-secure. For 
example, whether the displayed web page and associated frames are provided 
via a secure socket layer (SSL), i.e. a web page from an HTTPS address 
(secure), or simply via an HTTP address (non-secure), respectively. The present 
30 invention uses "Web Components" to solve the aforementioned problems, as well 
as other problems that will become apparent from an understanding of the 
following description. Specifically, a Web Component according to the present 
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local client. Further, the local client can itself be a web server or other server that 
is hosting a web site accessible to one or more end users. 

Specifically, the Web Component is capable of automatically and 
5 dynamically generating at least one web page that is customized for display or 
hosting on the local client in response to specific function properties provided to 
the Web Component. Consequently, the Web Component is capable of being 
configured in any of a plurality of ways by simply setting one or more of the 
function properties in accordance with the communication from the local client to 
10 the remote server. As a result, separate local clients addressing the same Web 
Component can display or host either the same, more, less, or different 
3 information, having either the same or a different appearance, using either a 

secure or non-secure state by simply passing different function properties to the 
sj same Web Component or by calling an intermediate page that sets these 

15 function properties. As for using an intermediate page, the local client may 

request a web page (i.e. an intermediate web page or "entry web page") that in 
. turn, sets properties that are passed to the Web Component for dynamically 

r^" generating a web page that is ultimately returned to the local client. In other 

k; words, a single Web Component automatically and dynamically generates one or 

Q 20 more uniquely customized web pages for display or hosting on one or more local 
clients by processing function properties passed to the Web Component via a 
network or Internet by the local clients. Simply stated, the Web Component 
behaves differently depending upon how the function properties are set. 

25 For example, by passing a first set of parameters to the Web Component, 

a first local client displays or hosts at least one different web page than a second 
local client that passes a second set of parameters to the same Web 
Component. Clearly, any number of local clients can send any combination of 
supported parameters to the Web Component to display or host visually or 

30 functionally different web pages automatically and dynamically configured in 
response to the parameters provided by each local client. Consequently, the 
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same Web Component automatically and dynamically generates unique web 
pages in response to unique communications from separate local clients. 
Clearly, any number of functions and function properties may be associated with 
a Web Component to automatically and dynamically generate any number of 
5 unique web pages in response to any number of unique communications. 

Further, in one embodiment, intermediate pages store the desired values that the 
Web Component should use, and the intermediate page, in turn, passes the 
parameters to the Web Component. This intermediate page stores desired 
parameters or values, then calls the Web Component, passing these values in 
1 0 order to have the Web Component dynamically generate a web page having 
desired characteristics. 

Each implementation of a particular Web Component may be represented 
by one or more HTML or scriptable (i.e., ASP, CGI, PERL, etc.) pages on a 

1 5 virtual root of an Internet web server. As stated above, a Web Component may 
represent a single web page or a series of web pages representing, primarily, a 
single user process such as performing a calculation or applying for a loan, or a 
multi-user process such as a multi-player game. The actual script and HTML 
content for a Web Component are shared across all implementations or 

20 instantiations of the Web Component, thereby allowing substantial code reuse, 
with corresponding lower test costs and faster time-to-market for a new user of 
the component. Web components are preferably designed to run in an HTML 
frame but alternately, may run in a separate window. 

25 Particular implementations or instantiations of an individual Web 

Component may include, for example, images that appear in the page(s) of the 
Web Component (via an image path defined for the Web Component, as 
described above); colors for each of the particular styles of text (including color 
changes associated with events performed on the page); textual content that 

30 appears in specific sections of the component (managed with included files with 
same names but different file paths); parameters that affect the functionality of 
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the cx)mponent (i.e. URLs associated with a form post, hiding or showing content 
specific to a Web Component implementation (i.e. whether to collect a credit card 
number as part of a user process); and hiding or showing links to other Web 
Components based on whether a particular user web site is allowed access to 
5 those components. 

In one embodiment, the Web Component has a plurality of different 
URL's, or addresses, as entry web pages or "entry points" to the Web 
Component. Consequently, a specific entry point acts as the Web Component 

10 users "public interface" to the component and can, for example, accept 

parameters appended to the URL and modify content or functionality based on 
what is passed; validate that the referring URL is authorized to host the Web 
Component; redirect to an error page if the referring URL is not authorized to 
host the Web Component; set or override default values for function properties 

15 used in the Web Component; hide the internal page structure of the site such as 
by providing a "published" consistent interface similar to typical software 
components such as COM-based objects; and/or allow logging of data 
associated with use of the component by a particular implementation. 

20 Use of user-specific entry points allows for predefined customization of the 

dynamically and automatically generated web pages by using customization 
information stored in a Web Component accessible computer readable storage 
medium including a database, script, or other electronic file, containing function 
parameter data specific to local clients. Further, while specific entry points are 

25 different for each local client, local clients may access a Web Component 

through one or more entry points. Consequently, local clients may cause the 
Web Component to generate different web pages, or similar web pages having 
either more or less features by simply entering the same Web Component 
through unique entry points specific to that local client. Again, entry points are 

30 simply URL's or addresses used to call the Web Component. 
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As for whether a web page and associated frames are secure or non- 
secure, the Web Component dynamically remotely controls whether the 
displayed web page and associated frames displayed within a window of the web 
browser are secure or non-secure. Specifically, when a web site displayed on a 
5 local client passes function properties to the Web Component, in one 

embodiment, the Web Component dynamically and automatically generates a 
secure web page. Further, the Web Component then automatically directs the 
calling web site to replace any non-secure frames with secure frames, and 
directs the calling website to load a specified web page and/or component 
1 0 securely in the appropriate frame in response to the request. As the frames are 
preferably hosted on a local client web server hosting the web site, the local 
client simply acts to replace any non-secure frames with secure frames via a 
local HTTPS address in response to the direction from the Web Component. 

1 5 The replacement or switch of frames from non-secure to secure, or from 

secure to non-secure is accomplished because a security state application or 
script is preferably running on either the local client or remote server which waits 
for direction from the Web Component as to a desired security state for the 
frames of the web site displayed by the local client. Alternately, the security state 
20 application or script may simply wait for direction or pointers as to what web 

pages to display for each frame, without caring whether the requested pages are 
secure or non-secure. In such cases, the security state application or script 
simply causes the local client/web server to swap the pages or components 
displayed in each frame with whatever pages or components are requested via 
25 direction from the Web Component. Consequently, unlike the prior schemes 
described above, the web page and all associated frames are secure at the 
same time. Similarly, where the web page and associated frames are all secure, 
and the local client web site passes function properties to the Web Component 
such that the Web Component dynamically and automatically generates a non- 
30 secure web page, the Web Component further automatically directs the calling 
web site to replace any secure frames with non-secure frames, as described 
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above. Consequently, a mixture of a non-secure web page with secure frames is 
avoided. 

One method for controlling whether the local client web site has either 
5 secure or non-secure frames is for the local client web site to initially pass the 
addresses for both the secure and non-secure frames to the Web Component. 
Consequently, when the Web Component determines that a secure page, or 
non-secure page, should be generated as a result of the function properties 
passed to the Web Component by the local client web site, the Web Component 

10 will further pass the address of the component page within the secure frames, or 
non-secure frames, respectively, back to the local client web site. The local client 
web site will then set the contents of the component's frame to the secure 
frames, or non-secure frames, respectively. Another method is for the local client 
web site to pre-register with the remote server hosting the Web Component and 

1 5 provide secure/non-secure frame address information to that server for storage in 
at least one computer readable storage medium including a database, script or 
other electronic file accessible by the Web Component. In this case, the Web 
Component will simply look up the appropriate address in the database, script or 
other electronic file and provide it back to the local client web site when directing 

20 that web site to display either secure or non-secure frames as described above. 

In a simple working example of the Web Component, during the design of 
a Web Component, a determination of what parameters or function properties of 
the Web Component will be alterable by a particular implementation is made. 

25 Each HTML text type is covered by a CSS Style and therefore can be 

customized for each implementation or instantiation of the Web Component. 
After these function properties have been determined, script and/or include files 
are created to augment the look or behavior of the Web Component for each 
function parameter, based on the range of possible values for each function 

30 properties. Further examples of function properties include a string value such 
as, for example, "CompanyName" that is set to the company name of a company 
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using the Web Component, or a binary decision such as whether to show a link. 
Other function properties include flags as to whether to display one of more types 
of information or fragments of content based on the desired implementation. 

Once the Web Component has been developed, it is implemented by first 
creating an entry-point ASP, HTML page or database calls passing the identity of 
the component implementation. The entry point page generally resides on a 
different web virtual directory within the remote server than the HTML and ASP 
pages representing the Web Component itself. This entry point page may collect 
parameters passed by the host of the Web Component and uses these 
parameters to set function property values in the Web Component. Alternately, 
as described above, the entry-point page itself will set the values of the individual 
function properties before redirecting to the actual HTML or scriptable (i.e., ASP, 
CGI, PERL, etc.) pages comprising the Web Component. These function 
properties may be stored on the redirect page as script variables, or read from a 
server-based object used to fetch values from a name/value pair storage based 
on the function parameter name provided. The entry point pages will also set the 
virtual path to any image folders and include folders used to store images and 
include files specific to each Web Component implementation, i.e., specific to 
each local client or "individual user," as described above. 

In addition to the just described benefits, other advantages of the present 
invention will become apparent from the detailed description which follows 
hereinafter when taken in conjunction with the accompanying drawing figures. 

DESCRIPTION OF THE DRAWINGS 

The specific features, aspects, and advantages of the present invention 
will become better understood with regard to the following description, appended 
claims, and accompanying drawings where: 
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FIG. 1 is a diagram depicting a general-purpose computing device 
constituting an exemplary system for implementing the present invention. 

FIG. 2 illustrates an exemplary arcliitectural flow diagram for implementing 
the present invention 

FIG. 3 is an exemplary flow diagram for implementing a worthing example 
of automatic and dynamic web page generation in accordance with the present 
invention. 

FIG. 4 is an exemplary flow diagram for implementing a working example 
of automatic control of web page security state in accordance with the present 
invention. 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 

In the following description of the preferred embodiments of the present 
invention, reference is made to the accompanying drawings, which form a part 
hereof, and in which is shown by way of illustration specific embodiments in 
which the invention may be practiced. It is understood that other embodiments 
may be utilized and structural changes may be made without departing from the 
scope of the present invention. 

Exemplary Operating Environment: 

Figure 1 illustrates an example of a suitable computing system 
environment 100 on which the invention may be implemented. The computing 
system environment 100 is only one example of a suitable computing 
environment and is not intended to suggest any limitation as to the scope of use 
or functionality of the invention. Neither should the computing environment 100 



be interpreted as having any dependency or requirement relating to any one or 
combination of components illustrated in the exemplary operating environment 
100. 

The invention is operational with numerous other general purpose or 
special purpose computing system environments or configurations. Examples of 
well known computing systems, environments, and/or configurations that may be 
suitable for use with the invention include, but are not limited to, personal 
computers, server computers, hand-held, laptop or mobile devices, 
multiprocessor systems, microprocessor-based systems, set top boxes, 
programmable consumer electronics, network PCs, minicomputers, mainframe 
computers, distributed computing environments that include any of the above 
systems or devices, and the like. 

The invention may be described in the general context of computer- 
executable instructions, such as program modules, being executed by a 
computer. Generally, program modules include routines, programs, objects, 
components, data structures, etc. that perform particular tasks or implement 
particular abstract data types. The invention may also be practiced in distributed 
computing environments where tasks are performed by remote processing 
devices that are linked through a communications network. In a distributed 
computing environment, program modules may be located in both local and 
remote computer storage media including memory storage devices. With 
reference to Figure 1, an exemplary system for implementing the invention 
includes a general purpose computing device in the form of a computer 110. 

Components of computer 110 may include, but are not limited to, a 
processing unit 120, a system memory 130, and a system bus 121 that couples 
various system components including the system memory to the processing unit 
120. The system bus 121 may be any of several types of bus structures 
including a memory bus or memory controller, a peripheral bus, and a local bus 
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using any of a variety of bus architectures. By way of example, and not 
limitation, such architectures include Industry Standard Architecture (ISA) bus, 
Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA) bus, Video 
Electronics Standards Association (VESA) local bus, and Peripheral Component 
Interconnect (PCI) bus also known as Mezzanine bus. 

Computer 110 typically includes a variety of computer readable media. 
Computer readable media can be any available media that can be accessed by 
computer 1 10 and includes both volatile and nonvolatile media, removable and 
non-removable media. By way of example, and not limitation, computer readable 
media may comprise computer storage media and communication media. 
Computer storage media includes both volatile and nonvolatile, removable and 
non-removable media implemented in any method or technology for storage of 
information such as computer readable instructions, data structures, program 
modules or other data. Computer storage media includes, but is not limited to, 
RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, 
digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, 
magnetic tape, magnetic disk storage or other magnetic storage devices, or any 
other medium which can be used to store the desired information and which can 
accessed by computer 110. Communication media typically embodies computer 
readable instructions, data structures, program modules or other data in a 
modulated data signal such as a carrier wave or other transport mechanism and 
includes any information delivery media. The term "modulated data signal" 
means a signal that has one or more of its characteristics set or changed in such 
a manner as to encode information in the signal. By way of example, and not 
limitation, communication media includes wired media such as a wired network 
or direct-wired connection, and wireless media such as acoustic, RF, infrared 
and other wireless media. Combinations of the any of the above should also be 
included within the scope of computer readable media. 
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The system memory 130 includes computer storage media in the form of 
volatile and/or nonvolatile memory such as read only memory (ROM) 131 and 
random access memory (RAM) 132. A basic input/output system 133 (BIOS), 
containing the basic routines that help to transfer information between elements 
within computer 110, such as during start-up, is typically stored in ROM 131. 
RAM 132 typically contains data and/or program modules that are immediately 
accessible to and/or presently being operated on by processing unit 120. By way 
of example, and not limitation, Figure 1 illustrates operating system 134, 
application programs 135, other program modules 136, and program data 137. 

The computer 110 may also include other removable/non-removable, 
volatile/nonvolatile computer storage media. By way of example only, Figure 1 
illustrates a hard disk drive 141 that reads from or writes to non-removable, 
nonvolatile magnetic media, a magnetic disk drive 1 51 that reads from or writes 
to a removable, nonvolatile magnetic disk 152, and an optical disk drive 155 that 
reads from or writes to a removable, nonvolatile optical disk 156 such as a CD 
ROM or other optical media. Other removable/non-removable, 
volatile/nonvolatile computer storage media that can be used in the exemplary 
operating environment include, but are not limited to, magnetic tape cassettes, 
flash memory cards, digital versatile disks, digital video tape, solid state RAM, 
solid state ROM, and the like. The hard disk drive 141 is typically connected to 
the system bus 121 through a non-removable memory interface such as interface 
140, and magnetic disk drive 151 and optical disk drive 155 are typically 
connected to the system bus 121 by a removable memory interface, such as 
interface 150. 

The drives and their associated computer storage media discussed above 
and illustrated in Figure 1 , provide storage of computer readable instructions, 
data structures, program modules and other data for the computer 110. In Figure 
1, for example, hard disk drive 141 is illustrated as storing operating system 144, 
application programs 145, other program modules 146, and program data 147. 
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Note that these components can either be the same as or different from 
operating system 134, application programs 135, other program modules 136, 
and program data 137. Operating system 144, application programs 145, other 
program modules 146, and program data 147 are given different numbers here to 
illustrate that, at a minimum, they are different copies. A user may enter 
commands and information into the computer 110 through input devices such as 
a keyboard 162 and pointing device 161, commonly referred to as a mouse, 
trackball or touch pad. Other input devices (not shown) may include a 
microphone, joystick, game pad, satellite dish, scanner, or the like. These and 
other input devices are often connected to the processing unit 120 through a user 
input interface 160 that is coupled to the system bus 121 , but may be connected 
by other interface and bus structures, such as a parallel port, game port or a 
universal serial bus (USB). A monitor 191 or other type of display device is also 
connected to the system bus 121 via an interface, such as a video interface 190. 
In addition to the monitor, computers may also include other peripheral output 
devices such as speakers 197 and printer 196, which may be connected through 
an output peripheral interface 195. 

The computer 110 may operate in a networked environment using logical 
connections to one or more remote computers, such as a remote computer 180. 
The remote computer 180 may be a personal computer, a server, a router, a 
network PC, a peer device or other common network node, and typically includes 
many or all of the elements described above relative to the computer 110, 
although only a memory storage device 181 has been illustrated in Figure 1. The 
logical connections depicted in Figure 1 include a local area network (LAN) 171 
and a wide area network (WAN) 173, but may also include other networks. Such 
networking environments are commonplace in offices, enterprise-wide computer 
networks, intranets and the Internet. 

When used in a LAN networking environment, the computer 110 is 
connected to the LAN 171 through a network interface or adapter 170. When 
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used in a WAN networking environment, the computer 110 typically includes a 
modem 172 or other means for establishing communications over the WAN 173, 
such as the Internet. The modem 172, which may be internal or external, may be 
connected to the system bus 121 via the user input interface 160, or other 
appropriate mechanism. In a networked environment, program modules 
depicted relative to the computer 1 10, or portions thereof, may be stored in the 
remote memory storage device. By way of example, and not limitation, Figure 1 
illustrates remote application programs 185 as residing on memory device 181. 
It will be appreciated that the network connections shown are exemplary and 
other means of establishing a communications link between the computers may 
be used. 

The exemplary operating environment having now been discussed, the 
remaining part of this description will be devoted to a discussion of the program 
modules and processes embodying the present invention. 

System Overview: 

The present invention involves a new system and process using "Web 
Components" for automatically controlling whether a displayed web page and 
any associated frames displayed within a window of a web browser are secure or 
non-secure. A Web Component according to the present invention uses the 
same script and HTML for all implementations of the Web Component, 
regardless of which, or how many, unique local clients make use of the Web 
Component to automatically remotely control the security state of a web page 
and any associated frames. This code reuse is accomplished by using entry web 
pages, or "entry points," as described in further detail below, to set the value of 
function properties or parameters of the Web Component for dynamically and 
automatically remotely controlling the security state of a web page and any 
associated frames. The script and/or HTML of the Web Component pages does 
not change based on each new implementation or instantiation. Consequently, 
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little setup work is required for each implementation, and only a basic verification 
test pass is typically completed for each implementation. 

Additionally, in a further embodiment, these Web Components are also 
useful for automatically generating uniquely customized web pages. In this 
context, at least one dynamically customizable Web Component is provided on a 
remote server to define what information (i.e. the information content) will be in a 
web page displayed by the Internet browser on a local client or transmitted to the 
Internet browser by the local client. In this context, a "local client" refers to a 
local client, a web server, a web site, a web page, an end-user computer, a 
specific server hosting web pages, any server or web page request originating 
from specific domains or IP addresses, any other computer system or application 
capable of accessing the remote server, or any combination of the 
aforementioned computers, servers, applications or processes. Examples of 
types of information that may be displayed include, for example, text, images 
(motion or still), audio data, applets, scripts, forms, hyperlinks, or any other data, 
information, or content that can be provided via the Internet from a remote server 
to a local client. 

Fig. 2 illustrates one exemplary architectural/flow diagram for 
implementing the present invention as described above, with the dashed lines 
representing the aforementioned altemate embodiments and/or optional 
components or connections. 

In general, with reference to Fig. 2, at least one dynamically customizable 
Web Component 200 is provided on a remote server 205 to define the security 
state of a web page and any associated frames, as well as defining what 
information (i.e. the information content) will be displayed in the web page by the 
Internet browser or similar application on any number of local clients 210, 215 or 
220. In this context, the "local client"210, 215 or 220, refers to a local client 
computer, a web server, a web site, a web page, an end-user computer, a 
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specific server hosting web pages, any server or web page request originating 
from specific domains or IP addresses, any other computer system or application 
capable of accessing the remote server 205, or any combination of the 
aforementioned computers, servers, applications or processes. 

With respect to controlling the security state, the Web Component 200 is 
used to control whether the displayed web page and associated frames 
displayed within a window of the web browser are secure or non-secure. For 
example, whether the displayed web page and associated frames are provided 
via a secure socket layer (SSL), i.e. a web page from an HTTPS address 
(secure), or simply via an HTTP address (non-secure), respectively. 

Examples of types of information that may be displayed by the web 
component 200 include, for example, text, images (motion or still), audio data, 
applets, scripts, forms, hyperlinks, or any other data, information, or content that 
can be provided via the Internet from the remote server205 to a local client 210, 
215 or 220. 

Further, in one embodiment, the Web Component 200 defines how the 
displayed information will appear to a user, i.e. the color, style, layout, border, 
background, font size, type, style and characteristics, or any other desired 
parameters for defining the appearance of the information displayed by the 
Internet browser on the local client. 

In another embodiment, alternate images for each individual instantiation 
of the Web Component 200 are preferably stored in at least one computer 
readable storage medium including a database, script or other electronic file 225 
or 230 addressable by the Web Component 200, using a file path stored as a 
parameter of the instance of the Web Component for dynamically and 
automatically generating the web page. Similarly, in another embodiment, text 
files that contain Web Component-specific textual data are preferably copied 
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and/or altered, again using one or more file paths stored as parameters of the 
instance of the Web Component 200 for dynamically and automatically 
generating the web page. Use of alternate images and/or text files, as described 
for the preceding embodiments, provides for simple customization of the Web 
Component 200 by providing the ability to pre-define items such as images 
and/or text for use in specific instantiations of the Web Component. 

Finally, in another embodiment, the system and process of the present 
invention employs each of the aforementioned embodiments, or any combination 
thereof in automatically defining the information displayed in at least one web 
page, the appearance of that information, and the security state of the displayed 
web page and frames associated with that web page. 

Operation: 

In general, the Web Component 200 represents at least one dynamically 
configurable web page, and is comprised of at least one encapsulated web- 
based feature or function for defining one or more of information content, 
information appearance, and security state as described above. Consequently, 
one or more unique Web Components 200 can be combined to form a complete 
web site, or portions thereof. The Web Component 200 is customizable in that it 
is automatically and dynamically configured by setting one or more function 
properties associated with each function in response to a communication to the 
remote server 205 from a local client 210, 215 or 220. Further, the local client 
210, 215 or 220 can itself be a web server or other server that is hosting a web 
site accessible to one or more end users 235, 240, or 245. 

Specifically, the Web Component 200 is capable of automatically and 
dynamically generating at least one web page that is customized for display or 
hosting on the local client 210, 215, or 220 in response to specific function 
properties provided to the Web Component. Consequently, the Web Component 
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200 is capable of being configured in any of a plurality of ways by simply setting 
one or more of the function properties in accordance with the communication 
from the local client to the remote server. As a result, separate local clients 210, 
21 5 or 220 addressing the same Web Component 200 can display or host either 
5 the same, more, less, or different infomnation, having either the same or a 
different appearance, using either a secure or non-secure state, by simply 
passing different function properties to the same Web Component or by calling 
an intermediate page 250 that sets these function properties. Further, different 
intermediate pages 250 can be called by the local clients 210, 215 or 220 in 

1 0 order to pass different function properties to the same Web Component 200. As 
for using the intermediate page 250 the local client 210, 215 or 220 may request 
any of a number of web pages (i.e. an intermediate web page 250) that in turn, 
set properties that are passed to the Web Component 200 for dynamically 
generating a web page that is ultimately returned to the local client, which may 

15 be further provided to a web site accessible to one or more end users 235, 240, 
or 245. In other words, a single Web Component 200 automatically and 
dynamically generates one or more uniquely customized web pages for display 
or hosting on one or more local clients 210, 215 or 220 by processing function 
properties passed to the Web Component via a network or Internet by any of the 

20 local clients. Simply stated, the Web Component 200 behaves differently 
depending upon how the function properties are set. 

For example, by passing a first set of parameters to the Web Component 
200, a first local client 210 displays or hosts at least one different web page than 
25 a second local client 215 that passes a second set of parameters to the Web 
Component. Clearly, any number of local clients 21 , 215, or 220 can send any 
supported combination of parameters to the Web Component 200 to display or 
host visually or functionally different web pages automatically and dynamically 
configured in response to the parameters provided by each local client. 

30 
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In particular, in one trivial example, the Web Component 200 includes 
functions for providing a financial calculator applet, a scientific calculator applet, 
a page background color of blue, red, green or yellow, and an image from a 
database, script, or other electronic or file path 225 or 230, specific to the 
implementation of the Web Component, as described above. 

Using the example above, the first local client 210 passes parameters to 
the Web Component 200, either directly, or via the intermediate page 250, 
requesting a web page displaying the financial calculator and a blue background. 
The Web Component 200 then automatically and dynamically generates a web 
page, having a financial calculator on a blue background, which is transmitted 
from the remote server 205 to the first local client 210. Similarly, the second 
local client 215 addressing the same Web Component 200 passes parameters to 
the Web Component requesting a web page displaying both a financial calculator 
and a scientific calculator, with a yellow page background. The Web Component 
200 then automatically and dynamically generates a web page, having both a 
financial calculator and a scientific calculator on a yellow background, which is 
transmitted from the remote server 205 to the second local client 215. Similarly, 
a third local client 220 addressing the same Web Component 200 passes 
parameters to the Web Component requesting a web page displaying a scientific 
calculator, a green page background, and a known image from the database, 
script or other electronic file 225 or 230. The Web Component 200 then 
automatically and dynamically generates a web page, having a scientific 
calculator on a green background along with the known image, which is 
transmitted from the remote server 205 to the third local client 220. 

In accordance with this trivial example, three unique web pages have 
been automatically and dynamically generated by the same Web Component 
200 in response to a unique communication from each of three separate local 
clients 210, 215, and 220. Clearly, any number of functions and function 
properties may be associated with a Web Component 200 to automatically and 
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dynamically generate any number of unique web pages in response to any 
number of unique communications. It is also possible that any number of 
intermediate pages 250 may store the desired values that the Web Component 
should use, and the intermediate pages, in turn, pass the parameters to the Web 
Component 200. For example, one intermediate page 250 may be a 
conventional Active Server Page (ASP), called, for instance, 
"GreenFinancialCalculator.asp," that stores the parameters "Color=Green" and 
"Type=Financial" and then call the Web Component 200, passing these values in 
order to have the Web Component dynamically generate a web page having a 
financial calculator on a green background in accordance with the preceding 
example. 

Each implementation of a particular Web Component 200 may be 
represented by one or more HTML or scriptable (i.e., ASP, CGI, PERL, etc.) 
pages on a virtual root of an Internet web server. As stated above, a Web 
Component 200 may represent a single web page of a series of web pages 
representing, primarily, a single user process such as performing a calculation or 
applying for a loan, or a multi-user process such as a multi-player game. The 
actual script and HTML content for a Web Component 200 are shared across all 
implantations or instantiations of the Web Component, thereby allowing 
substantial code reuse, with corresponding lower test costs and faster time-to- 
market for a new user of the component. Web components 200 are preferably 
designed to run in an HTML frame but alternately, may run in a separate window. 

Particular implementations or instantiations of an individual Web 
Component 200 may include, for example, images that appear in the page(s) of 
the Web Component (via an image path defined for the Web Component, as 
described above); colors for each of the particular styles of text (including color 
changes associated with events performed on the page); textual content that 
appears in specific sections of the component (managed with included files with 
same names but different file paths); parameters that affect the functionality of 
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the component (i.e. URLs associated with a form post, hiding or showing content 
specific to a Web Component implementation (i.e. whether to collect a credit card 
number as part of a user process); and hiding or showing links to other Web 
Components based on whether a particular user web site is allowed access to 
those components. 

In one embodiment, the Web Component200 has a plurality of different 
URL's, or addresses, as entry web pages or "entry points"255 and 260 to the 
Web Component. Consequently, a specific entry point255 or 260 acts as a users 
"public interface" to the Web Component 200 and can, for example, accept 
parameters appended to the URL andautomatically modify content or 
functionality based on what is passed; validate that the referring URL is 
authorized to host the Web Component; redirect to an error page if the referring 
URL is not authorized to host the Web Component; set or override default values 
for function properties used in the Web Component; hide the internal page 
structure of the site such as by providing a "published" consistent interface 
similar to typical software components such as COM-based objects; and/or allow 
logging of data associated with use of the Web Component by a particular 
implementation. 

Use of user-specific entry points 255 or 260 allows for predefined 
customization of the dynamically and automatically generated web pages by 
using customization information stored in a Web Component accessible 
database, script, or other electronic file 225 or 230 containing function parameter 
data specific to local clients 210, 215, or 220. Further, while specific entry points 
255 or 260 are different for each local client 210, 215, or 220, local clients may 
access a Web Component200 through one or more entry points. Consequently, 
a particular local client, i.e. local client 210, can cause the Web Component200 
to generate different web pages, or similar web pages having either more or less 
features by simply entering the same Web Component through unique entry 
points specific to that local client. Again, entry points are simply URL's or 
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addresses, with or without parameters appended to the URL, used to call the 
Web Component 200. 

As for whether a web page and associated frames are secure or non- 
secure, as discussed above, in one embodiment, the Web Component 200 is 
used to control whether the displayed web page and associated frames 
displayed within a window of the web browser are secure or non-secure. 
Specifically, when a web site displayed on a local client passes function 
properties to the Web Component, in one embodiment, the Web Component 
dynamically and automatically generates a secure web page. Further, the Web 
Component then automatically directs the calling web site to replace any non- 
secure frames with secure frames, and directs the calling website to load a 
specified web page and/or component securely in the appropriate frame in 
response to the request. As the frames are preferably hosted on a local client 
web server hosting the web site, the local client simply acts to replace any non- 
secure frames with secure frames via a local HTTPS address in response to the 
direction from the Web Component. 

The replacement or switch of frames from non-secure to secure, or from 
secure to non-secure is accomplished because a security state application or 
script is preferably running on either the local client or remote server which waits 
for direction from the Web Component as to a desired security state for the 
frames of the web site displayed by the local client. Alternately, the security state 
application or script may simply wait for direction or pointers as to what web 
pages to display for each frame, without caring whether the requested pages are 
secure or non-secure. In such cases, the security state application or script 
simply causes the local client/web server to swap the pages or components 
displayed in each frame with whatever pages or components are requested via 
direction from the Web Component. Consequently, unlike the prior schemes 
described above, the web page and all associated frames are secure at the 
same time. Similarly, where the web page and associated frames are all secure. 
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and the local client web site passes function properties to the Web Connponent 
such that the Web Component dynamically and automatically generates a non- 
secure web page, the Web Component further automatically directs the calling 
web site to replace any secure frames with non-secure frames, as described 
5 above. Consequently, a mixture of a non-secure web page with secure frames is 
avoided. 

One method for controlling whether the local client web site has either 
secure or non-secure frames is for the local client web site to initially pass the 

1 0 addresses for both the secure and non-secure frames to the Web Component. 
Consequently, when the Web Component determines that a secure page, or 
non-secure page, should be generated as a result of the function properties 
passed to the Web Component by the local client web site, the Web Component 
will further pass the address of the component page within the secure frames, or 

15 non-secure frames, respectively, back to the local client web site. The local client 
web site will then set the contents of the component's frame to the secure 
frames, or non-secure frames, respectively. Another method is for the local client 
web site to pre-register with the remote server hosting the Web Component and 
provide secure/non-secure frame address information to that server for storage in 

20 a database, script, or other electronic file accessible by the Web Component. In 
this case, the Web Component will simply look up the appropriate address in the 
database, script, or other electronic file and provide it back to the local client web 
site when directing that web site to display either secure or non-secure frames as 
described above. 

25 

Working Examples: 

The following two examples illustrate working examples in accordance 
with the present invention. The first example details the use of a Web 
30 Component to automatically and dynamically generate customized web pages. 
The second example details the use of the same Web Component to 
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automatically and dynamically remotely control the security state of a web page 
and associated frames. Further, in accordance with the preceding discussion, it 
should be appreciated that individual Web Components according to the present 
invention are capable of 1) automatically and dynamically generating customized 
web pages; 2) controlling the security state of web pages and any associated 
frames; or 3) automatically and dynamically generating customized web pages, 
while at the same time automatically controlling the security state of those web 
pages and any associated frames. 

I. Automatic Customization of Web Pages: 

Fig. 3 illustrates a working example according to the present invention. In 
particular, in a simple working example of the Web Component 200, during the 
design of a Web Component, a determination of what parameters or function 
properties, images, include files, etc. of the Web Component will be alterable by 
a particular implementation (i.e. a particular user or calling web site) is made. In 
this example, each HTML text type is covered by a Cascading Style Sheet (i.e. a 
"CSS Style") and therefore can be customized for each implementation or 
instantiation of the Web Component 200. Cascading Style Sheets (CSS) is a 
conventional feature added to HTML that gives both Web site developers and 
users more control over how different elements of web pages are displayed. 

After the function properties have been determined, script and/or include 
flies are created to augment the look or behavior of the Web Component 200 for 
each function parameter, based on a range of possible values for each of the 
function properties. Further examples of function properties include a string 
value such as "CompanyName" that is set to the company name of a company 
using the Web Component 200 or a binary decision such as whether to show a 
link. Other function properties include flags as to whether to display one of more 
types of information or fragments of content based on the desired 
implementation. 
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Once the Web Component 200 has been developed, it is implemented by 
first creating an entry-point ASP, HTML page or database calls passing the 
identity of the component implementation. The entry point page 305 or 310 
generally resides on a different web virtual directory within the remote server 205 
than the HTML and ASP pages representing the Web Component 200 itself. 
This entry point page 305 or 310 may collect parameters passed by the host of 
the Web Component 200 and uses these parameters to set function property 
values in the Web Component. Alternately, as described above, the entry point 
page 305 or 310 itself will set the values of the individual function properties 
before redirecting to the actual HTML or scriptable (i.e., ASP, CGI, PERL, etc.) 
pages comprising the Web Component 200. These function properties may be 
stored on the redirect page as script variables, or read from a server-based 
object used to fetch values from a name/value pair storage based on the function 
parameter name provided. The entry point pages 305 or 310 will also set the 
virtual path to any image folders and include folders, such as an electronic 
database, script, or other electronic file 325 or 330, used to store images and 
include files specific to each Web Component implementation, i.e., specific to 
each local client 315 or 320 or "individual user," as described above. 

Given this exemplary discussion of one method for implementing the Web 
Component 200, the following example describes how a simple one-page Web 
Component illustrated by Fig. 3 may be implemented: 

First, a web page is created for the Web Component 200. This exemplary 
Web Component 200 has a default name/address such as, for example: 

http://WebComponent.Com/Components/Component1/Default.asp 

Further, this exemplary Web Component 200 contains one image "Logo.gif," one 
text string variable called "CompanyName," one include file called "Include.inc," a 
functional parameter on whether to show a company address called 
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"ShowAddress," and generic code or script for providing loan information (i.e. a 
"Loan Finder" 360) to an end-user. 

To implement the exemplary Web Component 200 for a particular 
company, i.e. "Company A", an entry point page 310 is created. This page is 
called, for example: 

http://WebComponent.Com/CompanyA/Entrypoint.asp 
This page uses a server-side script to set the values of: 

ImagePath = http://WebComponent.Com/CompanyA/lmages 
CompanyName = "Company A" 
ShowAddress = "True" 

IncludePath = http://WebComponent.Com/CompanyA/lnclude 

Similarly, to implement the exemplary Web Component 200 for a second 
company, i.e. "Company B", a second entry point page 305 is created called, for 
example: 

http://WebComponent.Com/CompanyB/Entrypoint.asp 
This page also uses a server-side script to set the values of: 

ImagePath = http://WebComponent.Com/CompanyB/lmages 
CompanyName = "Company B" 
ShowAddress = "False" 

IncludePath = http://WebComponent.Com/CompanyB/lnclude 

An include file for Company A (i.e., Include.inc) has Company A-specific 
text describing the company and the address of the company and is stored in the 
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specified IncludePath. The image Logo.gif is specific to Company A, and is 
stored in the specified ImagePath folder. The Web Component automatically 
looks for the value of "ShowAddress" for Company A, and because it is set to 
"True," the Web Component will automatically generate a web page displaying 
the address information from the include file. Similarly, an include file for 
Company B has Company B-specific text describing the company and the 
address of the company and is stored in the specified IncludePath. In this case, 
the image Logo.gif is specific to Company B, and is stored in the specified 
ImagePath folder for Company B. Again the Web Component 200 automatically 
looks for the value of "ShowAddress," and because, for Company B, it is set to 
"False," the Web Component will not display the address information from the 
include file in the automatically generated web page for Company B. 

Further, because the exemplary Web Component 200 also includes 
generic code or script for providing loan information to an end-user, the web 
component will provide this code in the automatically generated web page for 
each unique local client 315 or 320. Specifically, given the aforementioned 
parameters for Company A and Company B, the Web Component 200 will 
automatically generate a web page 335 for a Company A website 340 that 
includes the Company A image "Logo.gif 345, the name "Company A" 350 and 
the address 355 for Company A in combination with the "Loan Finder" 360 
functionality described above. Similarly, the Web Component 200 will 
automatically generate a web page 365 for a Company B web site 370 that 
includes the Company B image "Logo.gif 375 and the name "Company B" 380 in 
combination with the aforementioned "Loan Finder" 360 functionality. While the 
appearance of these two automatically generated web pages 335 and 365 are 
different, i.e. different names and images, both share the "Loan Finder" 360 
functionality. 

Finally, the Web Component 200 may also draw on one or more 
databases, scripts, or other electronic files 385 to provide specific data, text, 
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images, scripts, etc. For example, the images for either or both Company A or 
Company B, can be hosted on the remote sen/er 205, and provided to the Web 
Component 200 when the Web Component automatically generates customized 
web pages as described above. 

5 

Clearly, the same Web Component 200 is used in this working example to 
automatically generate two unique web pages, automatically customized for 
separate local clients 315 and 320 by simply using two separate predefined entry 
points 305 or 31 0 to access the Web Component. Further, any amount of 

10 commonality may also be included in such automatically generated web pages, 
such as, for example, by providing one or more common scripts, applets, etc., 
such as the aforementioned "Loan Finder" 360 script. Further, simply updating 
common scripts such as "Loan Finder" 360 in the Web Component 200 serves to 
automatically update any calling web sites the next time that such web sites 

1 5 make use of the Web Component. Consequently, as described above, only one 
test pass of an updated script, such as "Loan Finder" 360, is needed to verify 
proper functionality on any of a plurality of web sites. 



IL Automatic Remote Control of Web Page Security State: 

20 

Fig. 4 illustrates a working example for automatically setting the security 
state of a web page and associated frames in accordance with the present 
invention. In particular, this simple working example extends the preceding 
working example by using the Web Component 200 for automatically generating 
25 customized web pages as described above while also remotely controlling the 
security state of those web pages and any associated frames. 



Specifically, expanding on the previous working example to include 
automatic control of security state, a web page is created for the Web 
30 Component 200. This exemplary Web Component 200 has a default 
name/address such as, for example: 
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http://WebComponent.Com/Components/Component1/Default.asp 



Further, this exemplary Web Component 200 contains one image 
"Logo.gif," one text string variable called "CompanyName," one include file called 
"Include.inc," a functional parameter on whether to show a company address 
called "ShowAddress," a functional parameter on whether to use secure or non- 
secure frames called "SecureFrames," and generic code or script for providing 
the "Loan Finder" 360 functionality to an end-user, as described above. In this 
example, the Web Component 200 is designed to automatically generate a first 
web page for displaying the image, a second web page for displaying the 
company name, and a third web page for displaying the company address and 
providing the "Loan Finder" 360 functionality. 

To implement the exemplary Web Component 200 for a particular 
company, i.e. "Company B", while using the Web Component for remotely 
controlling web page security, at least one entry point page 306 and 307 is 
created. A first entry point page 306 is called, for example: 

http://WebComponent.Com/CompanyB/Entrypoint_1.asp 
This entry point page 306 uses a server-side script to set the values of: 

ImagePath = http://WebComponent.Com/CompanyB/lmages 
CompanyName = "Company B" 
ShowAddress = "False" 
SecureFrames = "True" 

IncludePath = http://WebComponent.Com/CompanyB/lnclude 
A second entry point page 307 is called, for example: 

http://WebComponent.Com/CompanyB/Entrypoint_2.asp 
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This entry point page 307 uses a server-side script to set tine values of: 

ImagePath = http://WebComponent.Com/CompanyB/lmages 
CompanyName = "Company B" 
5 ShowAddress = "False" 

SecureFrames = "False" 

IncludePath = http://WebComponent.Com/CompanyB/lnclude 

Assuming use of the first entry point page 306, an include file for 
10 Company B (i.e., Include.inc) has Company B-specific text describing the 
company and the address of the company and is stored in the specified 
IncludePath. The image Logo.gif is specific to Company B, and is stored in the 
specified ImagePath folder. The Web Component automatically looks for the 
value of "ShowAddress" for Company B, and because it is set to "False," the 
1 5 Web Component will automatically generate a web page that does not display 
the address information from the include file. Further, the Web Component 
automatically looks for the value of "SecureFrames," and because it is set to 
"True", the Web Component will automatically direct a security state script 440 
running on the local client computer 320 hosting the web site 370 for Company B 
20 to swap any non-secure frames of the displayed web page 365 with secure web 
pages using one of the methods described above. 

Specifically, in this working example, it is assumed that the local client 
computer 320 hosts both secure and non-secure frames for the Company B web 

25 site 370. Consequently, when a user selects a hyperlink that causes the 

Company B web site 370 to access the Web Component 200 via the first entry 
point page 306, the Web Component simply passes the local addresses for the 
secure frames to the Company B web site 370 via the security state script 440. 
The Company B web site then automatically loads the secure frames as 

30 described above. Further, In one embodiment, as described above, a security 

state script 450 runs on the remote server 205. In this alternate embodiment, the 
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Web Component simply passes the local addresses for the secure frames to the 
Company B web site 370 via the remote security state script 450. The Company 
B web 370 site then automatically loads the secure frames as described above. 
Further, each of these frames includes links to the web pages automatically 
5 generated by the Web Component 200. 

Specifically, given the aforementioned parameters for Company B, the 
Web Component 200 automatically generates three web pages that will be 
displayed on the Company B web page 365. The Company B web page 365 

1 0 includes three frames 410, 420 and 430. Each of these frames is secure due to 
the frame swap described above. The first frame 410 displays a web page 
automatically generated by the Web Component 200 that includes the name 
"Company B" 380. The second frame 420 displays a web page automatically 
generated by the Web Component 200 that includes the Company B image 

1 5 "Logo.gif 375. The third frame 430 displays a web page automatically generated 
by the Web Component 200 that includes the "Loan Finder" 360 functionality 
described above. Consequently, it can be seen that the web component both 
automatically generated a customized web page 365 while further automatically 
setting the security state of each of the frames 410, 420, and 430 comprising the 

20 customized web page. 

Similarly, assuming selection of the second entry point page 307, with 
"SecureFrames" set to "False," the Web Component 200 will automatically direct 
the Company B web site 370 to swap any secure frames with non-secure frames, 

25 as described above. Again, given the aforementioned parameters for Company 
B, the Web Component 200 automatically generates three web pages that will be 
displayed on the Company B web page 365. As described above, the Company 
B web page 365 includes three frames 410, 420 and 430. Each of these frames 
is non-secure due to the frame swap described above. The first frame 41 0 

30 displays a web page automatically generated by the Web Component 200 that 
includes the name "Company B" 380. The second frame 420 displays a web 
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page automatically generated by the Web Component 200 that includes the 
Company B image "Logo.gif 375. The third frame 430 displays a web page 
automatically generated by the Web Component 200 that includes the "Loan 
Finder" 360 functionality described above. Consequently, it can be seen that the 
web component both automatically generated a customized web page 365 while 
further automatically setting the security state of each of the frames 410, 420, 
and 430 comprising the customized web page. 

Finally, the Web Component 200 may also draw on one or more 
databases, scripts, or other electronic files 385 to provide specific data, text, 
images, scripts, etc. For example, the images for Company B, can be hosted on 
the remote server 205, and provided to the Web Component 200 when the Web 
Component automatically generates customized web pages as described above. 

Clearly, the same Web Component 200 is used in this working example to 
automatically generate unique web pages having multiple frames as well as a 
desired security state by simply using two separate predefined entry points 306 
or 307 to access the Web Component. Further, while this example describes two 
multi-frame web pages that are identical with the exception of security state, 
clearly each of these web pages may also be different by simply providing for 
different parameters in each of the entry point pages 306 and 307, as described 
above. Further, simply updating common the entry point pages, or scripts such 
as "Loan Finder" 360 In the Web Component 200 serves to automatically update 
any calling web sites the next time that such web sites make use of the Web 
Component. Consequently, as described above, only one test pass of an 
updated entry point page or an updated script such as "Loan Finder" 360, is 
needed to verify proper functionality on any of a plurality of web sites. 

Further, in a third example of the security state capability of the Web 
Component 200, the Web Component simply passes the local addresses for the 
secure frames to the Company B web site 370 via the security state script 440 or 
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450, in response to Web Component access via the first or second entry point 
page 306 or 307. In this example, the Web Component 200 does not 
automatically generate web pages, it only directs the Company B web site to 
automatically load either secure or non-secure frames as described above, 
5 depending upon which entry point page 306 or 307 is used. The Company B 
web site 370 then automatically loads the secure or non-secure frames as 
described above. In this case, the frames are populated with whatever web 
pages are linked to each of the frames using conventional techniques. 

1 0 The foregoing description of the invention has been presented for the 

purposes of illustration and description. It is not intended to be exhaustive or to 
limit the invention to the precise form disclosed. Many modifications and 
variations are possible in light of the above teaching. It is intended that the 
scope of the invention be limited not by this detailed description, but rather by the 

15 claims appended hereto. 
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